home *** CD-ROM | disk | FTP | other *** search
/ CU Amiga Super CD-ROM 25 / CU Amiga Magazine's Super CD-ROM 25 (1998)(EMAP Images)(GB)(Track 1 of 2)[!][issue 1998-08].iso / CUCD / Programming / ixemul / sdk / man / cat2 / flock.0 < prev    next >
Encoding:
Text File  |  1998-06-15  |  3.4 KB  |  73 lines
  1.  
  2. FLOCK(2)                   UNIX Programmer's Manual                   FLOCK(2)
  3.  
  4. NNAAMMEE
  5.      fflloocckk - apply or remove an advisory lock on an open file
  6.  
  7. SSYYNNOOPPSSIISS
  8.      ##iinncclluuddee <<ssyyss//ffiillee..hh>>
  9.      ##ddeeffiinnee   LLOOCCKK__SSHH   11    //** sshhaarreedd lloocckk **//
  10.      ##ddeeffiinnee   LLOOCCKK__EEXX   22    //** eexxcclluussiivvee lloocckk **//
  11.      ##ddeeffiinnee   LLOOCCKK__NNBB   44    //** ddoonn''tt bblloocckk wwhheenn lloocckkiinngg **//
  12.      ##ddeeffiinnee   LLOOCCKK__UUNN   88    //** uunnlloocckk **//
  13.  
  14.      _i_n_t
  15.      fflloocckk(_i_n_t _f_d, _i_n_t _o_p_e_r_a_t_i_o_n)
  16.  
  17. DDEESSCCRRIIPPTTIIOONN
  18.      FFlloocckk() applies or removes an _a_d_v_i_s_o_r_y lock on the file associated with
  19.      the file descriptor _f_d. A lock is applied by specifying an _o_p_e_r_a_t_i_o_n pa-
  20.      rameter that is one of LOCK_SH or LOCK_EX with the optional addition of
  21.      LOCK_NB. To unlock an existing lock operation should be LOCK_UN.
  22.  
  23.      Advisory locks allow cooperating processes to perform consistent opera-
  24.      tions on files, but do not guarantee consistency (i.e., processes may
  25.      still access files without using advisory locks possibly resulting in in-
  26.      consistencies).
  27.  
  28.      The locking mechanism allows two types of locks: _s_h_a_r_e_d locks and
  29.      _e_x_c_l_u_s_i_v_e locks.  At any time multiple shared locks may be applied to a
  30.      file, but at no time are multiple exclusive, or both shared and exclu-
  31.      sive, locks allowed simultaneously on a file.
  32.  
  33.      A shared lock may be _u_p_g_r_a_d_e_d to an exclusive lock, and vice versa, sim-
  34.      ply by specifying the appropriate lock type; this results in the previous
  35.      lock being released and the new lock applied (possibly after other pro-
  36.      cesses have gained and released the lock).
  37.  
  38.      Requesting a lock on an object that is already locked normally causes the
  39.      caller to be blocked until the lock may be acquired.  If LOCK_NB is in-
  40.      cluded in _o_p_e_r_a_t_i_o_n, then this will not happen; instead the call will
  41.      fail and the error EWOULDBLOCK will be returned.
  42.  
  43. NNOOTTEESS
  44.      Locks are on files, not file descriptors.  That is, file descriptors du-
  45.      plicated through dup(2) or fork(2) do not result in multiple instances of
  46.      a lock, but rather multiple references to a single lock.  If a process
  47.      holding a lock on a file forks and the child explicitly unlocks the file,
  48.      the parent will lose its lock.
  49.  
  50.      Processes blocked awaiting a lock may be awakened by signals.
  51.  
  52. RREETTUURRNN VVAALLUUEESS
  53.      Zero is returned if the operation was successful; on an error a -1 is re-
  54.      turned and an error code is left in the global location _e_r_r_n_o.
  55.  
  56. EERRRROORRSS
  57.      The fflloocckk() call fails if:
  58.  
  59.      [EWOULDBLOCK]
  60.                    The file is locked and the LOCK_NB option was specified.
  61.  
  62.      [EBADF]       The argument _f_d is an invalid descriptor.
  63.  
  64.      [EINVAL]      The argument _f_d refers to an object other than a file.
  65.  
  66. SSEEEE AALLSSOO
  67.      open(2),  close(2),  dup(2),  execve(2),  fork(2)
  68.  
  69. HHIISSTTOORRYY
  70.      The fflloocckk() function call appeared in 4.2BSD.
  71.  
  72. 4.2 Berkeley Distribution      December 11, 1993                             2
  73.